Black Hat Asia 2025: Innovation in the SOC

The view in the Cisco XDR integrations page:

SOC of the Future: XDR + Splunk Cloud

Authored by: Ivan Berlinson, Aditya Raghavan

As the technical landscape evolves, automation stands as a cornerstone in achieving XDR outcomes. It’s a testament to the prowess of Cisco XDR that it boasts a fully integrated, robust automation engine.

Cisco XDR Automation embodies a user-friendly, no-to-low code platform with a drag-and-drop workflow editor. This innovative feature empowers your SOC to speed up its investigative and response capabilities. You can tap into this potential by importing workflows within the XDR Automate Exchange from Cisco, or by flexing your creative muscles and crafting your own.

Remember from our past Black Hat blogs, we used automation for creating incidents in Cisco XDR from Palo Alto Networks and Corelight.

The following automation workflows were built specifically for Black Hat use cases:

Category: Create or update an XDR incident

• Via Splunk Search API — XDR incident from Palo Alto Networks NGFW Threats Logs
• Via Splunk Search API — XDR incident from Corelight Notice and Suricata logs
• Via Splunk Search API — XDR incident from Cisco Secure Firewall Intrusion logs
• Via Splunk Search API — XDR Incident from ThousandEyes Alert
• Via Umbrella Reporting API — XDR Incident from Umbrella Security Events
• Via Secure Malware Analytics API — XDR Incident on samples submitted and convicted as malicious

Category: Notify/Collaborate/Reporting

• Webex Notification on new Incident
• Last 6 hours reports to Webex
• Last 24 hours reports to Webex

Category: Investigate

• Via Splunk Search API and Global Variables (Table) — Identify Room and Location (incident rules on status new)
• Identify Room and Location (incident playbook)
• Identify Room and Location (Pivot Menu on IP)
• Webex Interactive Bot: Deliberate Observable
• Webex Interactive Bot: Search in Splunk
• Webex Interactive Bot: Identify Room and Location

Category: Report

• XDR incident statistics to Splunk

Category: Correlation

Workflows Description

Via Splunk Search API: Create or Update XDR Incident

These workflows are designed to run every five minutes and search the Splunk Cloud instance for new logs matching certain predefined criteria. If new logs are found since the last run, the following actions are performed for each of them:

1. Create a sighting in XDR private intelligence, including several pieces of information useful for analysis during an incident investigation (e.g., source IP, destination IP and/or domain, destination port, authorized or blocked action, packet payload, etc.). These alerts can then be used to create or update an incident (see next steps), but also to enrich the analyst’s investigation (XDR Investigate) like other integrated modules.
2. Link the sighting to an existing or a new threat indicator
3. Create a new XDR incident or update an existing incident with the new sighting and MITRE TTP.
   • To update an existing incident, the workflow uses the method described below, enabling the analyst to have a complete view of the different stages of an incident, and to identify whether it could potentially be part of a Training Lab (several Assets performing the same actions):
     • If there is an XDR incident with the same observables related to the same indicator, then update the incident
     • If not, check if there is an XDR incident with the same observables and only if the observable type is IP or Domain then update the incident
     • If not, check if an XDR incident exists with the same target asset, then update the incident
     • If not, create a new incident

Identify Room and Location

It was important for the analysts to obtain as much information as possible to help them understand whether the malicious behavior detected as part of an incident was a true security incident with an impact on the event (a True Positive), or whether it was legitimate in the context of a Black Hat demo, lab and training (a Black Hat Positive).

One of the methods we used was a workflow to find out the location of the assets involved and the purpose of it. The workflow is designed to run:

• Automatically on new XDR incident and add the result in a note
• On demand via a task in the XDR incident playbook
• On demand via the XR pivot menu
• On demand via the Webex interactive bot

The workflow uses one or more IP addresses as input, and for each of them:

• Queries an array (global variable XDR), including the network address of each room/area of the event and purpose (Lab XYZ, Registration, Genera Wi-Fi, etc.)
• Runs a search in Splunk on Palo Alto Networks NGFW Traffic Logs to get the Ingress Interface of the given IP
• Run a search in Splunk on Umbrella Reporting Logs to get to the Umbrella Network Identities

Webex Notification and Interactive Bot

Proper communication and notification are key to ensure no incident is ignored.

In addition to Slack, we were leveraging Cisco Webex to receive a notification when a new incident was raised in Cisco XDR and an interactive Bot to retrieve additional information and help in the first step of the investigation.

Notification

On new incident an automation was triggering a workflow to grab a summary of the incident, trigger the enrichment of the location and purpose of the room (see previous workflow) and send a Notification in our collaborative room with details about the incident and a direct link to it in XDR.

Interactive Bot

An interactive Webex Bot tool was also used to help the analyst. Four commands were available to trigger a workflow in Cisco XDR via a Webhook and display the result as a message in Cisco Webex.

1. locate [ip] — Search for location and purpose for a given IP
2. deliberate [observable] — Obtain verdicts for a given observable (IP, domain, hash, URL, etc.) from the various threat intelligence sources available in Cisco XDR (native and integrated module)
3. splunk — Perform a Splunk search of all indexes for a given keyword and display the last two logs
4. csplunk [custom search query] — Search Splunk with a custom search query

Last 6/24 hours reports to Webex

Both workflows run every 6 hours and every 24 hours to generate and push to our Webex collaboration rooms a report including the Top 5 assets, domains and target IPs in the security event logs collected by Splunk from Palo Alto Networks Firewall, Corelight NDR and Cisco Umbrella (search […] | stats count by […]).

Merge XDR Incident

Cisco XDR uses several advanced techniques to identify a chain of attack and correlate various related security detections together in a single incident. However, sometimes only the analyst’s own investigation can reveal the link between the two. It was important for analysts to have the option, when they discover this link, of merging several incidents into one and closing the previously generated incidents.

We’ve designed this workflow with that in mind.

During the identification phase, the analyst can run it from the “merge incident” task in the Incident playbook of any of them.

At runtime, analysts will be prompted to select the observables that are part of the current incident that they wish to search for in other incidents that include them.

The workflow will then search in XDR for other incidents involving the same observables and report incidents found in the current incident notes.

Analysts are then invited via a prompt to decide and indicate the criteria on which they would like the merger to be based.

The prompts include:

• All incidents — Accept the list of incidents found and merge them all
• Manual lists of incidents — Manually enter the identifier of the incidents you wish to merge; the list may include the identifier of an incident discovered by the workflow or another discovered by the analyst
• Merge in a new incident or In the most recent one
• Close other incidents — Yes/No

The workflow then extracts all the information from the selected incident and creates a new one with all this information (or updates the most recent incident).

To make our threat hunters’ lives richer with more context from ours and our partners’ tools, we brought in Splunk Enterprise Security Cloud at the last Black Hat Europe 2024 event to ingest detections from Cisco XDR, Secure Malware Analytics, Umbrella, ThousandEyes, Corelight OpenNDR and Palo Alto Networks Panorama and visualize them into functional dashboards for executive reporting. The Splunk Cloud instance was configured with the following integrations:

1. Cisco XDR and Cisco Secure Malware Analytics, using the Cisco Security Cloud app
2. Cisco Umbrella, using the Cisco Cloud Security App for Splunk
3. ThousandEyes, using the Splunk HTTP Event Collector (HEC)
4. Corelight, using Splunk HTTP Event Collector (HEC)
5. Palo Alto Networks, using the Splunk HTTP Event Collector (HEC)

The ingested data for each integrated platform was deposited into their respective indexes. That made data searches for our threat hunters cleaner. Searching for data is where Splunk shines! And to showcase all of that, key metrics from this dataset were converted into various dashboards in Splunk Dashboard Studio. The team used the SOC dashboard from the last Black Hat Europe 2024 as the base and enhanced it. The additional work brought more insightful widgets needing the SOC dashboard broken into the following 4 areas for streamlined reporting:

1. Incidents

2. DNS

3. Network Intrusion

4. Network Metrics

With the charter for us at Black Hat being a ‘SOC within a NOC’, the executive dashboards were reflective of bringing networking and security reporting together. This is quite powerful and will be expanded in future Black Hat events, to add more functionality and expand its usage as one of the primary consoles for our threat hunters as well as reporting dashboards on the large screens in the NOC.

Threat Hunter’s Corner

Authored by: Aditya Raghavan and Shaun Coulter

In the Black Hat Asia 2025 NOC, Shaun staffed the morning shifts, and Aditya the afternoon shifts as usual. Unlike the earlier years, both hunters had plenty of rabbit holes to down into leading to a place of “involved joy” for both.

Activities involving malware what would be blocked on a corporate network must be allowed, within the confines of Black Hat Code of Conduct.

Fishing With Malware: Who Caught the Fish?

It all started with unusual network activity originating from a device in a lab class. Doesn’t it always?

That said, a device was found connecting to a website flagged as suspicious by threat intelligence systems. Next, this website was being accessed via a direct IP address which is quite unusual. And to top it all off, the device exchanged credentials in clear text.

Sounds like your typical phishing incident, and it raised our hunters’ eyebrows. The initial hypothesis was that a device had been compromised in a phishing attack. Given the nature of the traffic — bi-directional communication with a known suspicious website — this seemed like a classic case of a phishing exploit. We utilized Cisco XDR to correlate these detections into an incident and visualize the connections involved.

As is evident from the screenshot below, a detection from Corelight OpenNDR for possible phishing kicked this off. Further investigation revealed similar traffic patterns from other devices within the conference hall, this time on General Wi-Fi network as well.

The destination for all of them, 139.59.108.141, had been marked with a suspicious disposition by alphaMountain.ai threat intelligence.

Thanks to the automation implemented to query Umbrella Identities, the device’s location was quickly confirmed to be within the Advanced Malware Traffic Analysis class. The hunters’ used this function every single time to such effect that it was decided to automate this workflow to be run and response obtained for every incident so that the hunters’ have this data ready at hand as the first step while investigating the incident.

Next step, our threat hunters as expected dived into Cisco Splunk Cloud to investigate the logs for any additional context. This investigation revealed important insights such as the traffic from the device being in clear text, allowing the payload to be extracted. This discovery was key because it revealed that this was not a typical phishing attack but part of a training exercise.

Additionally, it was discovered several other devices from the same subnet were also communicating with the same suspicious destination. These devices exhibited nearly identical traffic patterns, further supporting the theory that this was part of a lab exercise.

The variation in the traffic volume from the different devices suggested that various students were at different stages of the lab.

Lessons Learned: The Lost Last Part of PICERL

Being able to adjust what is presented to an analyst on the fly is one of the most fun parts of working events. In many organizations, “lessons learned” from an incident or cluster of events are reviewed much later if at all, and recommendations enacted even later.

In the Black Hat event environment, we are consistently looking for improvements and trying new things; to test the limits of the tools we have on hand.

At Black Hat our mandate is to maintain a permissive environment, which results in a very tough job in determining actual malicious activity. Because there is so much activity, time is at a premium. Anything to reduce the noise and reduce the amount of time in triage is of benefit.

Repeated activity was seen, such as UPNP traffic causing false positives. Fine, easy to spot but still it clogs up the work queue, as each event was at first creating a single incident.

Noise such as this causes frustration and that in turn can cause errors of judgement in the analyst. Therefore, sharpening the analysts’ tools is of premium importance.

The entire BH team is always open to suggestions for improvement to the processes and automation routines that we run on XDR.

One of these was to place the Corelight NDR event payload directly into the description of an event entry in XDR.

This simple change provided the details needed directly in the XDR dashboard, without any pivot into other tools, shortening the triage process.

The above example shows activity in the Business Hall from demonstrator booths. It is clear to see what appears to be repeated beaconing of a vendor device and was therefore easy and quick to close. Previously this required pivoting to the Splunk search to query for the event(s) and if the information was not apparent, then again pivot to the submitting platform. Here is the review of lesson learned, and the application of recommendations, considered my process of investigation and automated those two steps.

Again, In the following example shows interesting traffic which looks like external scanning using ZDI tools.

Through having the payload form Corelight present in the event sequence in the XDR “Analyst workbench”, I was able to see: /autodiscover/autodiscover.json which is commonly used by Microsoft Exchange servers to provide autodiscovery information to clients like Outlook.

The presence of this path suggested a probing for Exchange services.

• @zdi/Powershell Query Param — @zdi may refer to the Zero Day Initiative, a known vulnerability research program. This could indicate a test probe from a researcher, or a scan that mimics or checks for vulnerable Exchange endpoints.
• User-Agent: zgrab/0.x — zgrab is an open-source, application-layer scanner, often used for internet-wide surveys (e.g., by researchers or threat actors).

The tool is likely part of the ZMap ecosystem, which more than likely means that it is someone performing scanning or reconnaissance operation on the Public IP for the event, making it worthy to continue monitoring.

The Event Name was “WEB APPLICATION ATTACK” not very descriptive but with our fine tuning by providing the detail directly in the incident findings, the information was quite literally at my fingertips.

Scareware, Video Streaming and Whatnot!

On 2nd April, one of the devices on the network reached out to a website flagged as “Phishing” by Umbrella.

At first, it was suspected that the queries were related to a training class because of the timing of the domain activity. For example, some of the domains were registered as recently as a month ago, with Umbrella showing activity beginning only on April 1st, coinciding with the start of the conference.

But if that were the case, we would expect to see many other attendees making the same requests from the training Wi-Fi SSID. This was not the case — in fact, across the event only a total of five IPs making these DNS queries and/or web connections were seen, and only one of those was connected to the training SSID. One of those five devices was that of an Informa sales employee. A NOC leader contacted them, and they acknowledged accidentally clicking on a suspicious link.

Christian Clasen expanded the search beyond the “Phishing” category and found heaps of searches for domains in a short window of time for questionable categories of adware, malware and adult sites.

On this device, this was followed by a detour to a pirated video streaming website (potentially an accidental click). This website then kicked off a chain of pops-up to various websites across the board including over 700 DNS queries to adult sites. We used Secure Malware Analytics to review the website, without getting infected ourselves.

Considering this potential chain of actions on that device, the same observable was detonated in Splunk Attack Analyzer for dynamic interaction and analysis. The report for the video streaming site shows the site reputation being questionable along with indicators for phish kits and crypto payments present.

So, back to the question: Are these all connected? Looking at the various instances of such spurious DNS queries, Christian collated such websites queried and the IPs they were hosted at. DNS queries to:

• adherencemineralgravely[.]com
• cannonkit[.]com
• cessationhamster[.]com
• pl24999848[.]profitablecpmrate[.]com
• pl24999853[.]profitablecpmrate[.]com
• playsnourishbag[.]com
• resurrectionincomplete[.]com
• settlementstandingdread[.]com
• wearychallengeraise[.]com
• alarmenvious[.]com
• congratulationswhine[.]com
• markshospitalitymoist[.]com
• nannyirrationalacquainted[.]com
• pl24999984[.]profitablecpmrate[.]com
• pl25876700[.]effectiveratecpm[.]com
• quickerapparently[.]com
• suspectplainrevulsion[.]com

Which resolved to common infrastructure IPs:

• 172[.]240[.]108[.]68
• 172[.]240[.]108[.]84
• 172[.]240[.]127[.]234
• 192[.]243[.]59[.]13
• 192[.]243[.]59[.]20
• 192[.]243[.]61[.]225
• 192[.]243[.]61[.]227
• 172[.]240[.]108[.]76
• 172[.]240[.]253[.]132
• 192[.]243[.]59[.]12

Which are known to be associated with the ApateWeb scareware/adware campaign. The nameservers for these domains are:

• ns1.publicdnsservice[.]com
• ns2.publicdnsservice[.]com
• ns3.publicdnsservice[.]com
• ns4.publicdnsservice[.]com

Which are authoritative for hundreds of known malvertising domains:

Given that one affected person acknowledged that they had clicked on a suspicious link, resulting in one of the events, we believe that these are unrelated to training and in fact unrelated to each other. A Unit42 blog can be referenced for the list of IOCs related to this campaign. Unit42’s post notes, “The impact of this campaign on internet users could be large, since several hundred attacker-controlled websites have remained in Tranco’s top 1 million website ranking list.” Well, that is a true positive in the SOC here.

Trufflehunter Monero Mining Attacks

Authored by: Ryan MacLennan

As part of doing some additional testing and providing better efficacy for our XDR product, we deployed a proof-of-value Firepower Threat Defense (FTD) and Firepower Management Center (FMC). It was receiving the same SPAN traffic that our sensor received for XDR Analytics, but it is providing a completely different set of capabilities, those being the Intrusion Detection capabilities.

Below we can see multiple triggers, from a single host, on the FTD about a Trufflehunter Snort signature. The requests are going out to multiple external IP addresses using the same destination port.

This was interesting because it looks as if this user on the network was attempting to attack these external servers. The question was, what is trufflehunter, are these servers malicious, is the attack on purpose, or is it legitimate traffic here at Black Hat for a training session or demo?

Taking one of the IP addresses in the list, I entered it into VirusTotal and it returned that it was not malicious. But it did return multiple subdomains related to that IP. Taking the top-level domain of those subdomains, we can do a further search using Umbrella.

Umbrella Investigate says this domain is a low risk and freeware/shareware. At this point we can say that Command and Control is not in play. So why are we seeing hits to this random IP/domain?

Taking the domain for this investigation and popping it into Splunk Attack Analyzer (SAA), we can explore the site. Basically, the owner of this domain is an avid explorer of knowledge and loves to tinker with tech, the main domain was used to host their blog. The many subdomains they had listed were for the different services they host for themselves on their site. They had an email service, Grafana, admin login and many other services hosted here. They even had an about section so you could get to know the owner better. For the privacy of the domain owner, I will omit their website and other information.

Now that we know this IP and domain are most likely not malicious, the question remained of why they were being targeted. Looking at their IP address in Shodan, it listed their IP as having port 18010 open.

Looking at a few other IPs that were being targeted, they all had that same port open. So, what is that port used for and what CVE is the Snort signature referencing?

We see below that the trufflehunter signature is related to CVE-2018-3972. It is a vulnerability that allows code execution if a specific version of the Epee library is used on the host. In this case, the vulnerable library is commonly used in the Monero mining application.

Doing a search on Google showed that port 18080 is commonly used for Monero peer-to-peer connections in a mining pool. But that is based off the AI summary. Can we truly trust that?

Going down the results, we find the official Monero docs and they certainly do say to open port 18080 to the world if you want to be a part of a mining pool.

We can see that there were attempts to get into these services, but they were not successful as there were no responses back to the attacker? How is an attacker able to find servers around the world to perform these attacks on?

The answer is fairly simple. In Shodan, you can search for IPs with port 18080 open. The attacker can then curate their list and perform attacks, hoping some will hit. They probably have it automated, so there is less work for them in this process. How can we, as defenders and the everyday person, prevent ourselves from showing up on a list like this?

If you are hosting your own services and need to open ports to the internet, you should try to limit your exposure as much as possible.

To alleviate this type of fingerprinting/scanning you should block Shodan scanners (if you can). They have a distributed system, and IPs change all the time. You can block scanning activities in general if you have a firewall, but there is no guarantee that it will prevent everything.

If you have an application, you developed or are hosting, there are other options like fail2ban, security groups in the cloud, or iptables that can be used to block these types of scans. These options can allow you to block all traffic to the service except from the IPs you want to access it.

Alternatives to opening the port to the Internet would be to setup up tunnels from one site to another or use a service that doesn’t expose the port but allows remote access to it via a subdomain.

Snort ML Triggered Investigation

Authored by: Ryan MacLennan

During our time at Black Hat Asia, we made sure Snort ML (machine learning) was enabled. And it was definitely worth it. We had multiple triggers of the new Snort feature where it was able to detect a potential threat in the http parameters of an HTTP request. Let us dive into this new detection and see what it found!

Looking at the events, we can see multiple different IPs from a training class and one on the General Wi-Fi network triggering these events.

Investigating the event with the 192 address, we can see what it alerted on specifically. Here we can see that it alerted on the ‘HTTP URI’ field having the parameter of ‘?ip=%3Bifconfig’. This looks like an attempt to run the ifconfig command on a remote server. This is usually done after a webshell has been uploaded to a site and it is then used to enumerate the host it is on or to do other tasks like get a reverse shell for a more interactive shell.

In the packet data we can see the full request that was made.

Looking at another host that was in a training we can see that the Snort ML signature fired on another command as well. This is exactly what we want to see, we know now that the signature is able to detect different http parameters and determine if they are a threat. In this example we see the attacker trying to get a file output using the command ‘cat’ and then the file path.

With this investigation, I was able to determine the general Wi-Fi user was a part of the class as they were using the same IP addresses to attack as the rest of the class. This was interesting because it was a class on pwning Kubernetes cluster applications. We were able to ignore this specific instance as it is normal in this context (we call this a ‘Black Hat’ positive event) but we never would have seen these attacks without Snort ML enabled. If I had seen this come up in my environment, I would consider it a high priority for investigation.

Some extras for you, we have some dashboard data for you to peruse and see the stats of the FTD. Below is the Security Cloud Control dashboard.

Next, we have the FMC overview. You can see how high the SSL client application was and what our encrypted visibility engine (EVE) was able to identify.

Lastly, we have a dashboard on the top countries by IDS events.

Identity Intelligence

Authored by: Ryan MacLennan

Last year, Black Hat asked Cisco Security if we could be the Single Sign-On (SSO) provider for all the partners in the Black Hat NOC. The idea is to centralize our user base, make access to products easier, provide easier user management, and to show role-based access. We started the proof-of-value at Black Hat Asia 2024 and partially deployed at Black Hat Europe 2024. We have successfully integrated with the partners in the Black Hat NOC to enable this idea started a year ago. Below is a screenshot of all the products we have integrated with from our partners and from Cisco.

In this screenshot above, we have the idea of the product owners having administrative access to their own products and everyone else being a viewer or analyst for that product. Allowing each partner to access each other’s tools for threat hunting. Below, you can see the logins of various users to different products.

As a part of this, we also provide Identity Intelligence, we use Identity Intelligence to determine the trust worthiness of our users and notify us when there is an issue. We do have a problem though. Most of the users are not at every Black Hat conference and the location of the conference changes each time. This affects our users’ trust scores as you can see below.

Looking at the screenshot below, we can see some of the reasons for the trust score differences. As the administrators of the products start to get ready for the conference, we can see the logins start to rise in February, March, and finally April. Many of the February and March logins are done from countries not in Singapore.

Below, we can see users with their trust level, how many checks are failing, last login, and many other details. This is a quick glance at a user’s posture to see if we need to take any action. Luckily most of these are the same issue mentioned before.

At the end of each show and after the partners can get the data, they need from their products, we move all non admin users from an active state to a disabled group, ensuring the Black Hat standard of zero-trust.

Cisco Unveils New DNS Tunneling Analysis Techniques

Authored by: Christian Clasen

Cisco recently announced a new AI-driven Domain Generation Algorithm (DGA) detection capability integrated into Secure Access and Umbrella. DGAs are used by malware to generate numerous domains for command and control (C2) communications, making them a critical threat vector via DNS. Traditional reputation-based systems struggle with the high volume of new domains and the evolving nature of DGAs. This new solution leverages insights from AI-driven DNS tunneling detection and the Talos threat research team to identify unique lexical characteristics of DGAs. The result is a 30% increase in real detections and a 50% improvement in accuracy, reducing both false positives and negatives. Enhanced detection is automatically enabled for Secure Access and Umbrella users with the Malware Threat category active.

Engineers from Cisco presented the technical details of this novel approach at the recent DNS OARC conference. The presentation discusses a method for detecting and classifying Domain Generation Algorithm (DGA) domains in real-world network traffic using Passive DNS and Deep Learning. DGAs and botnets are introduced, along with the fundamentals of Passive DNS and the tools employed. The core of the presentation highlights a monitoring panel that integrates Deep Learning models with Passive DNS data to identify and classify malicious domains within the São Paulo State University network traffic. The detector and classifier models, detailed in recently published scientific articles by the authors, are a key component of this system.

This is a key capability in environments like the Black Hat conference network where we need to be creative when interrogating network traffic. Below is an example of the detection we observed at Black Hat Asia.

Domain Name Service Statistics

Authored by: Christian Clasen and Justin Murphy

We install virtual appliances as critical infrastructure of the Black Hat network, with cloud redundancy.

Since 2018, we have been tracking DNS stats at the Black Hat Asia conferences. The historical DNS requests are in the chart below.

The Activity volume view from Umbrella gives a top-level level glance of activities by category, which we can drill into for deeper threat hunting. On trend with the previous Black Hat Asia events, the top Security categories were Malware and Newly Seen Domains.

In a real-world environment, of the 15M requests that Umbrella saw, over 200 of them would have been blocked by our default security policies. However, since this is a place for learning, we typically let everything fly. We did block the category of Encrypted DNS Query, as discussed in the Black Hat Europe 2024 blog.

We also track the Apps using DNS, using App Discovery.

• 2025: 4,625 apps
• 2024: 4,327 apps
• 2023: 1,162 apps
• 2022: 2,286 apps

App Discovery in Umbrella gives us a quick snapshot of the cloud apps in use at the show. Not surprisingly, Generative AI (Artificial Intelligence) has continued to increase with a 100% increase year-over-year.

Umbrella also identifies risky cloud applications. Should the need arise, we can block any application via DNS, such as Generative AI apps, Wi-Fi Analyzers, or anything else that has suspicious undertones.

Again, this is not something we would normally do on our General Wi-Fi network, but there are exceptions. For example, every so often, an attendee will learn a cool hack in one of the Black Hat courses or in the Arsenal lounge AND try to use said hack at the conference itself. That is obviously a ‘no-no’ and, in many cases, very illegal. If things go too far, we will take the appropriate action.

During the conference NOC Report, the NOC leaders also report of the Top Categories seen at Black Hat.

Overall, we are immensely proud of the collaborative efforts made here at Black Hat Asia, by both the Cisco team and all the partners in the NOC.

We are already planning for more innovation at Black Hat USA, held in Las Vegas the first week of August 2025.

Acknowledgments

Thank you to the Cisco NOC team:

• Cisco Security: Christian Clasen, Shaun Coulter, Aditya Raghavan, Justin Murphy, Ivan Berlinson and Ryan Maclennan
• Meraki Systems Manager: Paul Fidler, with Connor Loughlin supporting
• ThousandEyes: Shimei Cridlig and Patrick Yong
• Additional Support and Expertise: Tony Iacobelli and Adi Sankar

Also, to our NOC partners Palo Alto Networks (especially James Holland and Jason Reverri), Corelight (especially Mark Overholser and Eldon Koyle), Arista Networks (especially Jonathan Smith), MyRepublic and the entire Black Hat / Informa Tech staff (especially Grifter ‘Neil Wyler’, Bart Stump, Steve Fink, James Pope, Michael Spicer, Jess Jung and Steve Oldenbourg).

About Black Hat

Black Hat is the cybersecurity industry’s most established and in-depth security event series. Founded in 1997, these annual, multi-day events provide attendees with the latest in cybersecurity research, development, and trends. Driven by the needs of the community, Black Hat events showcase content directly from the community through Briefings presentations, Trainings courses, Summits, and more. As the event series where all career levels and academic disciplines convene to collaborate, network, and discuss the cybersecurity topics that matter most to them, attendees can find Black Hat events in the United States, Canada, Europe, Middle East and Africa, and Asia. For more information, please visit the Black Hat website.

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Security on social!

Cisco Security Social Channels

LinkedIn
Facebook
Instagram
X

Share: